Internet Engineering Task Force (IETF) A. Uzelac, Ed. 


Request for Comments: 6405 Global Crossing 
Category: Informational Y. Lee, Ed. 
ISSN: 2070-1721 Comcast Cable 


November 2011 


Voice over IP (VoIP) SIP Peering Use Cases 
Abstract 
This document depicts many common Voice over IP (VoIP) use cases for 
Session Initiation Protocol (SIP) peering. These use cases are 
categorized into static and on-demand, and then further sub- 
categorized into direct and indirect. These use cases are not an 
exhaustive set, but rather the most common use cases deployed today. 
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Introduction 


This document describes important Voice over IP (VoIP) use cases for 
SIP-based [RFC3261] peering. These use cases are determined by the 
Session PEERing for Multimedia INTerconnect (SPEERMINT) working group 
and will assist in identifying requirements and other issues to be 
considered for future resolution by the working group. 


Only use cases related to VoIP are considered in this document. 
Other real-time SIP communications use cases, like Instant Messaging 
(IM), video chat, and presence are out of scope for this document. 


The use cases contained in this document are described as 
comprehensive as possible, but should not be considered the exclusive 
set of use cases. 
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2. Terminology 


This document uses terms defined in [RFC5486]. Please refer to it 
for definitions. 


3. Reference Architecture 


The diagram below provides the reader with a context for the VoIP use 
cases in this document. Terms such as SIP Service Provider (SSP), 
Lookup Function (LUF), Location Routing Function (LRF), Signaling 
Path Border Element (SBE), and Data Path Border Element (DBE) are 
defined in [RFC5486]. 


The Originating SSP (O-SSP) is the SSP originating a SIP request. 

The Terminating SSP (T-SSP) is the SSP terminating the SIP request 
originating from the O-SSP. The assisting LUF and LRF Provider offer 
LUF and LRF services to the O-SSP. The Indirect SSP (I-SSP) is the 
SSP providing indirect peering service(s) to the O-SSP to connect to 


the T-SSP. 

+-------------------- +------------------------ +-------------------- + 
Originating SSP Assisting LUF and LRF Terminating SSP 
Domain Provider Domain Domain 

| | | | 

| +----- + +----—- + | +-----—- + +------ + | +----- + +---—- + | 

| |O-LUF| |O-LRF| | |A-LUF | | A-LRF| | |T-LUF| |T-LRF| | 

| +----- + +---—- + | +------ + +------ + | +----- + +---—- + | 

| | 

hi ------—- + +----- + +------------------------ + +----- + +------- + 

| |O-Proxy| |O-SBE| | Indirect SSP Domain | |T-SBE| |T-Proxy| | 

| +------- + +----- + | | +----- + $------- + | 

| | +---—- + +----- + | | 

| +---+ +----- + | |O-SBE| |O-DBE | | +----- + +---+ 
|uac|  |O-DBE| +----- + +----- + |T-DBE| |UAS| 
+---+ +---—- + +----—- + +---+ 

| | | | 

+--------------------— +------------------------ +--------------------— + 


General Overview 
Figure 1 


Note that some elements included in Figure 1 are optional. 
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4. Contexts of Use Cases 


Use cases are sorted into two general groups: static and on-demand 
peering [RFC5486]. Each group can be further sub-divided into Direct 
Peering and Indirect Peering [RFC5486]. Although there may be some 
overlap among the use cases in these categories, there are different 
requirements between the scenarios. Each use case must specify a 
basic set of required operations to be performed by each SSP when 
peering. 


These can include: 


o Peer Discovery - Peer discovery via a Lookup Function (LUF) to 
determine the Session Establishment Data (SED) [RFC5486] of the 
request. In VoIP use cases, a request normally contains a phone 
number. The O-SSP will input the phone number to the LUF and the 
LUF will normally return a SIP address of record (AOR) [RFC3261] 
that contains a domain name. 


o Next-Hop Routing Determination - Resolving the SED information is 
necessary to route the request to the T-SSP. The LRF is used for 
this determination. After obtaining the SED, the O-SSP may use 
the standard procedure defined in [RFC3263] to discover the next- 
hop address. 


o Call setup - SSPs that are interconnecting to one another may also 
define specifics on what peering policies need to be used when 
contacting the next hop in order to a) reach the next hop at all 
and b) prove that the sender is a legitimate peering partner. 
Examples: hard-code transport (TCP/UDP/TLS), non-standard port 
number, specific source IP address (e.g., in a private Layer 3 
network), which TLS client certificate [RFC5246] to use, and other 
authentication schemes. 


o Call reception - This step ensures that the type of relationship 
(static or on-demand, indirect or direct) is understood and 
acceptable. For example, the receiving SBE needs to determine 
whether the INVITE it received really came from a trusted member. 


5. Use Cases 
Please note there are intra-domain message flows within the use cases 


to serve as supporting background information. Only inter-domain 
communications are germane to this document. 
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5.1. Static Peering Use Cases 


Static peering [RFC5486] describes the use case when two SSPs form a 
peering relationship with some form of association established prior 
to the exchange of traffic. Pre-association is a prerequisite to 
static peering. Static peering is used in cases when two peers want 
a consistent and tightly controlled approach to peering. In this 
scenario, a number of variables, such as an identification method 
(remote proxy IP address) and Quality-of-Service (QoS) parameters, 
can be defined upfront and known by each SSP prior to peering. 


5.2. Static Direct Peering Use Case 


This is the simplest form of a peering use case. Two SSPs negotiate 
and agree to establish a SIP peering relationship. The peer 
connection is statically configured and the peer SSPs are directly 
connected. The peers may exchange interconnection parameters such as 
Differentiated Service Code Point (DSCP) [RFC2474] policies, the 
maximum number of requests per second, and proxy location prior to 
establishing the interconnection. Typically, the T-SSP only accepts 
traffic originating directly from the trusted peer. 


+-------------------- + +--------------------- + 
| O-SSP | | T-SSP | 
| tennant | | a | 
| )o-LUF | | | |T-LUF | | 
| | O-LRF | | | / | T-LRF | | 
/+----- +\ 4 +----- + 
| (2) (4,5, 6) | | / | 
| / x | (8,9) | 
|+------- + +----- + +----—- + +------—- +| 
| |O-Proxy|- (3) -|0-SBE+----- (7) ----- +T-SBE|- (10) -|T-Proxy| | 
| +------- + +----—- + +----- + +------- +| 
| | | 
| (1) (11) 
| | | | | | 
| +----- + +----- + +----- + +----- + | 
| | UAC +======|0-DBE+ (12) +T-DBE|=======+ UAS | | 
| +----- + +----- + +----—- + +----- + | 
+-------------------- + +--------------------- + 
example.com example.net 


Static Direct Peering Use Case 


Figure 2 
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The following is a high-level depiction of the use case: 


TS The User Agent Client (UAC) initiates a call via SIP INVITE to 
O-Proxy. O-Proxy is the home proxy for UAC. 


INVITE sip:+19175550100@example.com;user=phone SIP/2.0 

Via: SIP/2.0/TCP client.example.com:5060 
;branch=z9hG4bK74bf£9 

Max-Forwards: 10 

From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=12345 

To: Bob <sip:+19175550100@example.com; user=phone> 

Call-ID: abcde 

CSeq: 1 INVITE 

<allOneLine> 

Contact: <sip:+19175550100@client.example.com; user=phone; 

transport =tcp> 

</allOneLine> 


Note that UAC inserted its Fully Qualified Domain Name (FQDN) in the 
VIA and CONTACT headers. This example assumes that UAC has its own 
FQDN. 


2. UAC knows the User Agent Server’s (UAS’s) TN, but does not know 
UAS’s domain. It appends its own domain to generate the SIP URI 
in the Request-URI and TO header. O-Proxy checks the Request- 
URI and discovers that the Request-URI contains the user 
parameter "user=phone". This parameter signifies that the 
Request-URI is a phone number. So O-Proxy will extract the TN 
from the Request-URI and query the LUF for SED information from 
a routing database. In this example, the LUF is an ENUM 
[RFC6116] database. The ENUM entry looks similar to this: 


SORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. 
IN NAPTR ( 
10 
100 
my" 
"E2U+SIP" 
"I .*S!sip:+19175550100@example.net!" 
) 


This SED data can be provisioned by O-SSP or populated by the T-SSP. 
3. O-Proxy examines the SED and discovers the domain is external. 
Given the O-Proxy’s internal routing policy, O-Proxy decides to 


use O-SBE to reach T-SBE. O-Proxy routes the INVITE request to 
O-SBE and adds a Route header that contains O-SBE. 
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INVITE sip:+19175550100@example.net;user=phone SIP/2.0 

Via: SIP/2.0/TCP o-proxy.example.com:5060 
;branch=z9hG4bKye8ad 

Via: SIP/2.0/TCP client.example.com:5060 
;branch=z9hG4bK74bf£9; received=192.0.1.1 

Max-Forwards: 9 

Route: <sip:o-sbel.example.com;1r> 

Record-Route: <sip:o-proxy.example.com;1r> 

From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=12345 

To: Bob <sip:+19175550100@example.com; user=phone> 

Call-ID: abcde 

CSeq: 1 INVITE 

<allOneLine> 

Contact: <sip:+19175550100@client.example.com; user=phone; 

transport=tcp> 


</allOneLine> 
4. O-SBE receives the requests and pops the top entry of the Route 
header that contains "o-sbel.example.com". O-SBE examines the 
Request-URI and does an LRF for "example.net". In this example, 


the LRF is a Naming Authority Pointer (NAPTR) DNS query 
[RFC3403] of the domain name. O-SBE receives a NAPTR response 
from the LRF. The response looks similar to this: 


IN NAPTR ( 
50 
50 
Ton 
"SIP+D2T™ 


we 


_sip._tcp.t-sbe.example.net. ) 


IN NAPTR ( 
90 
50 
mou 
"SIP+D2U" 


_sip._udp.t-sbe.example.net. ) 


Ds Given the lower order for TCP in the NAPTR response, O-SBE 
decides to use TCP as the transport protocol, so it sends an SRV 
DNS query for the SRV record [RFC2782] for "_sip._tcp.t- 
sbe.example.net." to O-LRF. 
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ee priority weight port target 


IN SRV 0 2 5060 t-sbel.example.net. 
IN SRV 0 1 5060 t-sbe2.example.net. 

6. Given the higher weight for "t-sbel.example.net", O-SBE sends an 
A record DNS query for "t-sbel.example.net." to get the A 
record: 

;; DNS ANSWER 
t-sbel.example.net. INA 192.0.2.100 
t-sbel.example.net. INA 192.0.2.101 

Pee O-SBE sends the INVITE to T-SBE. O-SBE is the egress point to 
the O-SSP domain, so it should ensure subsequent mid-dialog 
requests traverse via itself. If O-SBE chooses to act as a 


back-to-back user agent (B2BUA) [RFC3261], it will generate a 
new INVITE request in next step. If O-SBE chooses to act as a 
proxy, it should record-route to stay in the call path. In this 
example, O-SBE is a B2BUA. 


INVITE sip:+19175550100@example.net;user=phone SIP/2.0 
Via: SIP/2.0/TCP o-sbel.example.com:5060 
;branch= z9hG4bK2d4zzz 
Max-Forwards: 8 
From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=54321 
To: Bob <sip:+19175550100@example.net; user=phone> 
Call-ID: abcde-osbel 
CSeq: 1 INVITE 
<allOneLine> 
Contact: <sip:+19175550100@o-sbel.example.com;user=phone; 
transport=tcp> 
</allOneLine> 


Note that O-SBE may re-write the Request-URI with the target domain 
in the SIP URI. Some proxy implementations will only accept the 
request if the Request-URI contains their own domains. 


8. T-SBE determines the called party home proxy and directs the 
call to the called party. T-SBE may use ENUM lookup or other 
internal mechanism to locate the home proxy. If T-SSP uses ENUM 


lookup, this internal ENUM entry is different from the external 
ENUM entry populated for O-SSP. In this example, the internal 
ENUM query returns the UAS’s home proxy. 
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SORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. 
IN NAPTR ( 
10 
100 
"it 
"E2U+SIP" 
"I. *S!sip:+19175550100@t-proxy.example.net!" 
) 


9. T-SBE receives the NAPTR record, and following the requirements 
in [RFC3263], queries DNS for the SRV records indicated by the 
NAPTR result. Not finding any, the T-SBE then queries DNS for 
the A record of domain "t-proxy.example.net.". 


7; DNS ANSWER 
t-proxy.example.net. INA 192.0.2.2 


10. T-SBE is a B2BUA, so it generates a new INVITE and sends it to 
UAS’s home proxy: 


INVITE sip:bob@t-proxy.example.net;user=phone SIP/2.0 
Via: SIP/2.0/TCP t-sbel.example.net:5060 
;branch= z9hG4bK28uyyy 
Max-Forwards: 7 
From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=54321 
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone> 
Call-ID: abcde-tsbel 
CSeq: 1 INVITE 
<allOneLine> 
Contact: <sip:+19175550100@t-sbel.example.net;user=phone; 
transport=tcp> 
</allOneLine> 
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11. Finally, UAS’s home proxy forwards the INVITE request to the 
UAS. 


INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0 
Via: SIP/2.0/TCP t-proxy.example.net:5060 
;branch= z9hG4bK28ul111 
Via: SIP/2.0/TCP t-sbel.example.net:5060 
;branch= z9hG4bK28uyyy; received=192.2.0.100 
Max-Forwards: 6 
Record-Route: <sip:t-proxy.example.net:5060;1r>, 
<sip:t-sbel.example.net:5060;1r> 
From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=54321 
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone> 
Call-ID: abcde-tsbel 
CSeq: 1 INVITE 
<allOneLine> 
Contact: <sip:+19175550100@t-sbel.example.net;user=phone; 
transport=tcp> 
</allOneLine> 


12. RTP is established between the UAC and UAS. Note that the media 
shown in Figure 2 passes through O-DBE and T-DBE, but the use of 
DBE is optional. 


5.2.1. Administrative Characteristics 


The static direct peering use case is typically implemented ina 
scenario where there is a strong degree of trust between the two 
administrative domains. Both administrative domains typically signa 
peering agreement that states clearly the policies and terms. 


5.2.2. Options and Nuances 


In Figure 2, O-SSP and T-SSP peer via SBEs. Normally, the operator 
will deploy the SBE at the edge of its administrative domain. The 
Signaling traffic will pass between two networks through the SBEs. 
The operator has many reasons to deploy an SBE. For example, the 
O-SSP may use [RFC1918] addresses for their UA and proxies. These 
addresses are not routable in the target network. The SBE can 
perform a NAT function. Also, the SBE eases the operation cost for 
deploying or removing Layer 5 network elements. Consider the 
deployment architecture where multiple proxies connect to a single 
SBE. An operator can add or remove a proxy without coordinating with 
the peer operator. The peer operator "sees" only the SBE. As long 
as the SBE is maintained in the path, the peer operator does not need 
to be notified. 
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When an operator deploys SBEs, the operator is required to advertise 
the SBE to the peer LRF so that the peer operator can locate the SBE 
and route the traffic to the SBE accordingly. 


SBE deployment is a decision within an administrative domain. Either 
one or both administrative domains can decide to deploy SBE(s). To 
the peer network, most important is to identify the next-hop address. 
This decision does not affect the network’s ability to identify the 
next-hop address. 


-3. Static Direct Peering Use Case - Assisting LUF and LRF 


This use case shares many properties with the Static Direct Peering 
Use Case Section 5.2. There must exist a pre-association between the 
O-SSP and T-SSP. The difference is O-SSP will use the Assisting LUF/ 
LRF Provider for LUF and LRF. The LUF/LRF Provider stores the SED to 
reach T-SSP and provides it to O-SSP when O-SSP requests it. 


4+----------------- + 
|LUF/LRF Provider | 
| | 
4+------- + 
+-+ A-LUF | | 
| / | A-LRF | | 
N A F +4+------- + E Sse ses Hs> + 
| O-SSP |Z 7 | T-SSP | 
| +------------ / (4,5,6) | +----- + | 
| / | / | T-LUF | 
(2) +-+/ +- |T-LRF 
hgh / | | E yee + | 
|o / J | | / (8,9) | 
|+------- + +----—- + +----—- + +------- +| 
| |O-Proxy|- (3) -|O-SBE+------- (7) ------- +T-SBE|-(10)-|T-Proxy| | 
4+------- + 4+----- + 4+----- + 4+------- + 
| | | | 
| (1) | | aD | 
| | | | | | 
| +----- + +----- + +----- + +----—- + | 
| | UAC +======|0-DBE+ (12) +T-DBE+=======+ UAS | 
| +----- + +----- + +----- + +----- + | 
4-------------------- + 4+--------------------- + 
example.com example.net 


Static Direct Peering with Assisting LUF and LRF 


Figure 3 
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The call flow looks almost identical to Static Direct Peering Use 
Case except that Steps 2, 4, 5, and 6 involve the LUF/LRF Provider 
instead of happening in O-SSP domain. 


Similar to Static Direct Peering Use Case, the O-DBE and T-DBE in 
Figure 3 are optional. 


5.3.1. Administrative Characteristics 


The LUF/LRF Provider supplies the LUF and LRF services for the O-SSP. 
Taken together, the LUF/LRF Provider, O-SSP, and T-SSP form a trusted 
administrative domain. To reach the T-SSP, the O-SSP must still 
require pre-arranged agreements for the peer relationship with the 
T-SSP. The Layer 5 policy is maintained in the O-SSP and T-SSP 
domains, and the LUF/LRF Provider may not be aware of any Layer 5 
policy between the O-SSP and T-SSP. 


A LUF/LRF Provider can serve multiple administrative domains. The 
LUF/LRF Provider typically does not share SED from one administrative 
domain to another administrative domain without appropriate 
permission. 


5.3.2. Options and Nuances 


The LUF/LRF Provider can use multiple methods to provide SED to the 
O-SSP. The most commonly used are an ENUM lookup and a SIP Redirect. 
The O-SSP should negotiate with the LUF/LRF Provider regarding which 
query method it will use prior to sending a request to the LUF/LRF 
Provider. 


The LUF/LRF Providers must be populated with the T-SSP’s AORs and 
SED. Currently, this procedure is non-standardized and labor 
intensive. A more detailed description of this problem has been 
documented in the work in progress [DRINKS]. 


5.4. Static Indirect Peering Use Case - Assisting LUF and LRF 


The difference between a Static Direct Use Case and a Static Indirect 
Use Case lies within the Layer 5 relationship maintained by the O-SSP 
and T-SSP. In the Indirect use case, the O-SSP and T-SSP do not have 
direct Layer 5 connectivity. They require one or multiple Indirect 
Domains to assist with routing the SIP messages and possibly the 
associated media. 


In this use case, the O-SSP and T-SSP want to form a peer 
relationship. For some reason, the O-SSP and T-SSP do not have 
direct Layer 5 connectivity. The reasons may vary, for example, 
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business demands and/or domain policy controls. Due to this indirect 
relationship, the signaling will traverse from the O-SSP through one 
or multiple I-SSPs to reach the T-SSP. 


In addition, the O-SSP is using a LUF/LRF Provider. This LUF/LRF 
Provider stores the T-SSP’s SED pre-populated by the T-SSP. One 
important motivation to use the LUF/LRF Provider is that the T-SSP 
only needs to populate its SED once to the provider. Using an LUF/ 
LRF Provider allows the T-SSP to populate its SED once, while any 
O-SSP T-SSP’s SED can use this LUF/LRF Provider. Current practice 
has shown that it is rather difficult for the T-SSP to populate its 
SED to every O-SSP who must reach the T-SSP’s subscribers. This is 
especially true in the Enterprise environment. 


Note that the LUF/LRF Provider and the I-SSP can be the same provider 
or different providers. 


+-----------------—- + 

| LUF/LRF Provider | 

| I-SSP | 

J tessa + | 

---+ A-LUF 
/ | A-LRF 
dea SSS SSS SSeS + / +------- + peSaSoeS SS sas SSe SSeS + 
| O-SSP | / / | T-SSP | 
| tee / / | : amiga + | 
| / | (4,5,6) | | T-LUF | | 
| j | / | +----+T-LRF | 
(2) + +--- / +----- + 
|7 / | | / (9,10) | 
|+------- + +----—- + +----- + +----—- + +------—- +| 
| |O-Proxy|- (3) -|O-SBE+- (7) -+I-SBE+- (8) --+T-SBE+- (11) -|T-Proxy | | 
| +------- + +----- + +----- + +----- + +------—- +| 
| | | 
| (1) (12) 
| | | | | | 
| +----- + +----- + +----- + +----—- + +----- + | 
| | UAC +=(13)=|0-DBE+=====+I-DBE+======+T-DBE+=======+ UAS | | 
| +----- + +----- + +----—- + +----- + +----- +| 
ooo 55555555 5 555 55 5 5 555 55 5 555 5 5 55 55555 5555-555 + 
example.com example.org example.net 


Indirect Peering via an LUF/LRF Provider and I-SSP (SIP and Media) 


Figure 4 


Uzelac & Lee Informational [Page 13] 


RFC 6405 VoIP SIP Peering Use Cases November 2011 


The following is a high-level depiction of the use case: 


TS The UAC initiates a call via SIP INVITE to the O-Proxy. The 
O-Proxy is the home proxy for the UAC. 


INVITE sip:+19175550100@example.com;user=phone SIP/2.0 

Via: SIP/2.0/TCP client.example.com:5060 
;branch=z9hG4bK74bf£9 

Max-Forwards: 10 

From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=12345 

To: Bob <sip:+19175550100@example.com; user=phone> 

Call-ID: abcde 

CSeq: 1 INVITE 

<allOneLine> 

Contact: <sip:+19175550100@client.example.com; user=phone; 

transport=tcp> 

</allOneLine> 


2. The UAC knows the UAS’s TN, but does not know the UAS’s domain. 
It appends its own domain to generate the SIP URI in the 
Request-URI and TO header. The O-Proxy checks the Request-URI 
and discovers that the Request-URI contains the user parameter 
"user=phone". This parameter indicates that the Request-URI is 
a phone number. So, the O-Proxy will extract the TN from the 
Request-URI and query the LUF for SED information from a routing 
database. In this example, the LUF is an ENUM database. The 
ENUM entry looks similar to this: 


SORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. 
IN NAPTR ( 
10 
100 
i a 
"E2U+SIP" 
"I .*S!sip:+19175550100@example.org!" 
) 


Note that the response shows the next-hop is the SBE in I-SSP. 
Alternatively, the O-SSP may have a pre-association with the I-SSP. 
As such, the O-SSP will forward all requests that contain an external 
domain in the Request-URI or an unknown TN to the I-SSP. The O-SSP 
will rely on the I-SSP to determine the T-SSP and route the request 
correctly. In this configuration, the O-SSP can skip Steps 2, 4, 5, 
and 6 and forward the request directly to the I-SBE. This 
configuration is commonly used in the Enterprise environment. 
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3. Given the O-Proxy’s internal routing policy, the O-Proxy decides 
to use the O-SBE to reach the I-SBE. The O-Proxy routes the 
INVITE request to the O-SBE and adds a Route header that 
contains the O-SBE. 


INVITE sip:+19175550100@example.org;user=phone SIP/2.0 

Via: SIP/2.0/TCP o-proxy.example.com:5060 
;branch=z9hG4bKye8ad 

Via: SIP/2.0/TCP client.example.com:5060 
;branch=z9hG4bK74bf9; received=192.0.1.1 

Max-Forwards: 9 

Route: <sip:o-sbel.example.com; 1r> 

Record-Route: <sip:o-proxy.example.com; 1r> 

From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=12345 

To: Bob <sip:+19175550100@example.net; user=phone> 

Call-ID: abcde 

CSeq: 1 INVITE 

<allOneLine> 

Contact: <sip:+19175550100@client.example.com; user=phone; 

transport=tcp> 

</allOneLine> 


4. The O-SBE receives the requests and pops the top entry of the 
Route header that contains "sip:o-sbel.example.com". The O-SBE 
examines the Request-URI and does an LRF for "example.org". In 
this example, the LRF is a NAPTR DNS query of the domain. The 
O-SBE receives a response similar to this: 


IN NAPTR ( 
50 
50 
ron 
"SITP+D2Z2T" 


_sip._tcp.i-sbe.example.org. ) 


IN NAPTR ( 
90 
50 
won 
"SIP+D2U" 


wie 


_sip._udp.i-sbe.example.org. ) 
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D's Given the lower order for TCP in the NAPTR response, the O-SBE 
decides to use TCP for transport protocol, so it sends an SRV 
DNS query for the SRV record for "_sip._tcp.i-sbe.example.org." 
to the O-LRF. 


Er priority weight port target 


IN SRV 0 2 5060 i-sbel.example.org. 
IN SRV 0 I 5060 i-sbe2.example.org. 
6. Given the higher weight for "i-sbel.example.org", the O-SBE 


sends a DNS query for an A record of "i-sbel.example.org." to 
get the A record: 


;; DNS ANSWER 

i-sbel.example.org. INA 192.0.2.200 

i-sbel.example.org. INA 192.0.2.201 

Ts The O-SBE sends the INVITE to the I-SBE. The O-SBE is the entry 

point to the O-SSP domain, so it should ensure subsequent mid- 
dialog requests traverse via itself. If the O-SBE chooses to 
act as a B2BUA, it will generate a new back-to-back INVITE 
request in the next step. If the O-SBE chooses to act as proxy, 


it should record-route to stay in the call path. In this 
example, the O-SBE is a B2BUA. 


INVITE sip:+19175550100@example.org;user=phone SIP/2.0 
Via: SIP/2.0/TCP o-sbel.example.com:5060 

;branch= z9hG4bK2d4zzz 
Max-Forwards: 8 


Route: <sip:i-sbel.example.org;1r> 
From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=54321 


To: Bob <sip:+19175550100@example.net; user=phone> 
Call-ID: abcde-osbel 

CSeq: 1 INVITE 

<allOneLine> 

Contact: <sip:+19175550100@o-sbel.example.com;user=phone; 
transport=tcp> 

</allOneLine> 


8. The I-SBE receives the request and queries its internal routing 
database on the TN. It determines that the target belongs to 
the T-SSP. Since the I-SBE is a B2BUA, the I-SBE generates a 
new INVITE request to the T-SSP. 
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INVITE sip:+19175550100@.example.net;user=phone SIP/2.0 
Via: SIP/2.0/TCP i-sbel.example.org:5060 
;branch= z9hG4bK2d4777 
Max-Forwards: 7 
Route: <sip:t-sbel.example.net;1r> 
From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=54321 
To: Bob <sip:+19175550100@example.net;user=phone> 
Call-ID: abcde-isbel 
CSeq: 1 INVITE 
<allOneLine> 
Contact: <sip:+19175550100@i-sbel.example.org; user=phone; 
transport=tcp> 
</allOneLine> 


Note that if the I-SSP wants the media to traverse through the I-DBE, 
the I-SBE must modify the Session Description Protocol (SDP) in the 
Offer to point to its DBE. 


Oo The T-SBE determines the called party home proxy and directs the 
call to the called party. The T-SBE may use ENUM lookup or 
another internal mechanism to locate the home proxy. If the 
T-SSP uses ENUM lookup, this internal ENUM entry is different 
from the external ENUM entry populated for O-SSP. This internal 
ENUM entry will contain the information to identify the next hop 
to reach the called party. In this example, the internal ENUM 
query returns the UAS’s home proxy. 


SORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. 
IN NAPTR ( 
10 
100 
my" 
"E2U+SIP" 
"IT. *S!sip:+19175550100@t-proxy.example.net!" 
) 


Note that this step is optional. If the T-SBE has other ways to 
locate the UAS home proxy, the T-SBE can skip this step and send the 
request to the UAS’s home proxy. We show this step to illustrate one 
of the many possible ways to locate UAS’s home proxy. 


10. The T-SBE receives the NAPTR record and, following the 
requirements in [RFC3263], queries the DNS for the SRV records 
indicated by the NAPTR result. Not finding any, the T-SBE then 
queries DNS for the A record of domain "t-proxy.example.net.". 
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7; DNS ANSWER 
t-proxy.example.net. INA 192.0.2.2 


11. T-SBE sends the INVITE to UAS’s home proxy: 


INVITE sip:+19175550100@t-proxy.example.net;user=phone SIP/2.0 
Via: SIP/2.0/TCP t-sbel.example.net:5060 
;branch= z9hG4bK28uyyy 
Max-Forwards: 6 
Record-Route: <sip:t-sbel.example.net:5060;1r> 
From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=54321 
To: Bob <sip:+19175550100@example.net; user=phone> 
Call-ID: abcde-tsbel 
CSeq: 1 INVITE 
<allOneLine> 
Contact: <sip:+19175550100@t-sbel.example.com;user=phone; 
transport=tcp> 
</allOneLine> 


12. Finally, the UAS’s home proxy forwards the INVITE request to the 
UAS. 


INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0 
Via: SIP/2.0/TCP t-proxy.example.net:5060 
;branch= z9hG4bK28ul111 
Via: SIP/2.0/TCP t-sbel.example.net:5060 
;branch= z9hG4bK28uyyy; received=192.2.0.100 
Max-Forwards: 5 
Record-Route: <sip:t-proxy.example.net:5060;1r>, 
<sip:t-sbel.example.net:5060;1r> 
From: Alice <sip:+14085550101@example.com; user=phone> 
;tag=54321 
To: Bob <sip:+19175550100@example.net; user=phone> 
Call-ID: abcde-tsbel 
CSeq: 1 INVITE 
<allOneLine> 
Contact: <sip:+19175550100@t-sbel.example.com;user=phone; 
transport =tcp> 
</allOneLine> 


13. In Figure 4, RIP is established between the UAC and UAS via the 
O-DBE, I-DBE and T-DBE. The use of DBE is optional. 


Uzelac & Lee Informational [Page 18] 


RFC 6405 VoIP SIP Peering Use Cases November 2011 


5.4.1. Administrative Characteristics 


This use case looks very similar to the Static Direct Peering Use 
Case with Assisting LUF and LRF. The major difference is the O-SSP 
and T-SSP do not have direct Layer 5 connectivity. Instead, O-SSP 
connects to the T-SSP indirectly via the I-SSP. 


Typically, an LUF/LRF Provider serves multiple O-SSPs. Two O-SSPs 
may use different I-SSPs to reach the same T-SSP. For example, 
O-SSP1 may use I-SSP1 to reach T-SSP, but O-SSP2 may use I-SSP2 to 
reach T-SSP. Given the O-SSP and T-SSP pair as input, the LUF/LRF 
Provider will return the SED of I-SSP that is trusted by O-SSP to 
forward the request to T-SSP. 


In this use case, there are two levels of trust relationship. The 
first trust relationship is between the O-SSP and the LUF/LRF 
Provider. The O-SSP trusts the LUF/LRF to provide the T-SSP’s SED. 
The second trust relationship is between the O-SSP and I-SSP. The 
O-SSP trusts the I-SSP to provide Layer 5 connectivity to assist the 
O-SSP in reaching the T-SSP. The O-SSP and I-SSP have a pre-arranged 
agreement for policy. Note that Figure 4 shows a single provider to 
supply both LUF/LRF and I-SSP, but O-SSP can choose two different 
providers. 


5.4.2. Options and Nuances 


Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP 
may deploy SBE and DBE for NAT traversal, security, transcoding, etc. 
The I-SSP can also deploy the SBE and DBE for similar reasons (as 
depicted in Figure 4). 


5.5. Static Indirect Peering Use Case 


This use case shares many properties with the Static Indirect Use 
Case with Assisting LUF and LRF. The difference is that the O-SSP 
uses its internal LUF/LRF to control the routing database. By 
controlling the database, the O-SSP can apply different routing rules 
and policies to different T-SSPs. For example, the O-SSP can use 
I-SSP1 and Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to 
reach T-SSP2. Note that there could be multiple I-SSPs and multiple 
SIP routes to reach the same T-SSP; the selection process is out of 
scope of this document. 
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4+-------------------- 4------------------- 4--------------------- + 
| O-SSP | I-SSP | T-SSP | 
+---—- + 4+----- + 
| -+0-LUF | | T-LUE | | 
| / |O-LRF+\ | | 9 +----+T-LRF | | 
E Oe o 
| /(2) \ (4,5,6) | /(9,10) | 
| +------- + +----- + +----—- + +----—- + +------—- +| 
|O-Proxy |- (3) -|O-SBE+-- (7) -+I-SBE+- (8) --+T-SBE+- (11) -|T-Proxy | 
4+------- + 4+----- + 4+----- + 4+----- + 4+------- + 
| | | | | | 
Jt d) | | (12) | 
| | | | | | 
| +----- + +----—- + +----- + +----—- + +----- + | 
| | UAC +=(13)=+0-DBE+======+1-DBE+======+T-DBE+=======+ UAS | | 
| +----- + +----- + +----- + +----—- + +----—- + | 
4-------------------------------------------------------------- + 
example.com example.org example.net 


Indirect Peering via I-SSP (SIP and Media) 
Figure 5 
5.5.1. Administrative Characteristics 

The Static Indirect Peering Use Case is implemented in cases where no 
direct interconnection exists between the originating and terminating 
domains due to either business or physical constraints. 
O-SSP <---> I-SSP = Relationship O-I 
In the O-I relationship, typical policies, features, or functions 
that deem this relationship necessary are number portability, 
ubiquity of termination options, security certificate management, and 
masquerading of originating VoIP network gear. 
T-SSP <---> I-SSP = Relationship T-I 
In the T-I relationship, typical policies, features, or functions 
observed consist of codec "scrubbing", anonymizing, and transcoding. 


The I-SSP must record-route and stay in the signaling path. The 
T-SSP will not accept any message sent directly from the O-SSP. 
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5.5.2. Options and Nuances 


In Figure 5, we show an I-DBE. Using an I-DBE is optional. For 
example, the I-DBE can be used when the O-SSP and T-SSP do not have a 
common codec. To involve an I-DBE, the I-SSP should know the list of 
codecs supported by the O-SSP and T-SSP. When the I-SBE receives the 
INVITE request, it will make a decision to invoke the I-DBE. An 
I-DBE may also be used if the O-SSP uses Secure Real-time Transport 
Protocol (SRTP) [RFC3711] for media and T-SSP does not support SRTP. 


5.6. On-Demand Peering Use Case 


On-demand peering [RFC5486] describes how two SSPs form the peering 
relationship without a pre-arranged agreement. 


The basis of this use case is built on the fact that there is no pre- 
established relationship between the O-SSP and T-SSP. The O-SSP and 
T-SSP do not share any information prior to the dialog initiation 
request. When the O-Proxy invokes the LUF and LRF on the Request- 
URI, the terminating user information must be publicly available. 
When the O-Proxy routes the request to the T-Proxy, the T-Proxy must 
accept the request without any pre-arranged agreement with the O-SSP. 


The On-demand Peering Use Case is uncommon in production. In this 
memo, we capture only the high-level descriptions. Further analysis 
is expected when this use case becomes more popular. 


5.6.1. Administrative Characteristics 


The On-demand Direct Peering Use Case is typically implemented ina 
scenario where the T-SSP allows any O-SSP to reach its serving 
subscribers. The T-SSP administrative domain does not require any 
pre-arranged agreement to accept the call. The T-SSP makes its 
subscribers information publicly available. This model mimics the 
Internet email model. The sender does not need an pre-arranged 
agreement to send email to the receiver. 


5.6.2. Options and Nuances 


Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP 
can decide to deploy the SBE. Since the T-SSP is open to the public, 
the T-SSP is considered to be a higher security risk than static 
model because there is no trusted relationship between the O-SSP and 
T-SSP. The T-SSP should protect itself from any attack launched by 
an untrusted O-SSP. 


Uzelac & Lee Informational [Page 21] 


RFC 6405 VoIP SIP Peering Use Cases November 2011 


6. Acknowledgments 


Michael Haberler, Mike Mammer, Otmar Lendl, Rohan Mahy, David 
Schwartz, Eli Katz and Jeremy Barkan are the authors of the early 
individual documents. Their use cases are captured in this document. 
Also, Jason Livingood, Daryl Malas, David Meyer, Hadriel Kaplan, John 
Elwell, Reinaldo Penno, Sohel Khan, James McEachern, Jon Peterson, 
Alexander Mayrhofer, and Jean-Francois Mule made many valuable 
comments related to this document. The editors would also like to 
extend a special thank you to Spencer Dawkins for his detailed review 
of this document. 


7. Security Considerations 


Session interconnect for VoIP, as described in this document, has a 
wide variety of security issues that should be considered. For 
example, if the O-SSP and T-SSP peer through public Internet, the 
O-SSP must protect the signaling channel and accept messages only 
from an authorized T-SSP. This document does not analyze the threats 
in detail. [RFC6404] discusses the different security threats and 
countermeasures related to VoIP peering. 
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